home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc771 < prev    next >
Encoding:
Text File  |  1991-04-20  |  18.2 KB  |  532 lines
  1.  
  2.                                                                         
  3. Network Working Group                                    V. Cerf  (ARPA)
  4. Request for Comments: 771                                J. Postel (ISI)
  5.                                                           September 1980
  6.  
  7.                           MAIL TRANSITION PLAN
  8.  
  9.  
  10. PREFACE
  11.  
  12.    This is a draft memo and comments are requested.
  13.  
  14. INTRODUCTION
  15.  
  16.    The principal aim of the mail service transition plan is to provide
  17.    orderly support for computer mail service during the period of
  18.    transition from the old ARPANET protocols to the new Internet
  19.    protocols.
  20.  
  21.    This plan covers only the transition from the current text computer
  22.    mail in the ARPANET environment to text computer mail in an Internet
  23.    environment.  This plan does not address a second transition from
  24.    text only mail to multimedia mail [10,11].
  25.  
  26.    The goal is to provide equivalent or better service in the new
  27.    Internet environment as was available in the ARPANET environment.
  28.    During the interim period, when both protocol environments are in
  29.    use, the goal is to minimize the impact on users and existing
  30.    software, yet to permit the maximum mail exchange connectivity.
  31.  
  32.    It is assumed that the user is familiar with both the ARPANET and
  33.    Internet protocol environments [1-8].  The Internet protocols are
  34.    designed to be used in a diverse collection of networks including the
  35.    ARPANET, Packet Radio nets, Satellite nets, and local nets (e.g.,
  36.    Ethernets, Ring nets); while the ARPANET protocol are, of course,
  37.    limited to the ARPANET.
  38.  
  39.    The Internet protocol environment specifies TCP as the host-to-host
  40.    transport protocol.  The ARPANET protocol environment specifies NCP
  41.    as the host-to-host transport protocol.  Both TCP and NCP provide
  42.    connection type process-to-process communication.  The problem in the
  43.    transition is to bridge these two different interprocess
  44.    communication systems.
  45.  
  46.    The objective of this plan is to specify the means by which the
  47.    ARPANET computer mail services may be extended into the Internet
  48.    system without disruptive changes for the users during the
  49.    transition.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                    1
  59.  
  60.  
  61.                                                                         
  62. September 1980                                                   RFC 771
  63. Mail Transition Plan                                                    
  64.  
  65.  
  66.  
  67. MODEL OF MAIL SERVICE
  68.  
  69.    The model of the computer mail system taken here separates the mail
  70.    composition and reading functions from the mail transport functions.
  71.    In the following, the discussion will be hoplessly TOPS20-oriented.
  72.    We appologize to users of other systems, but  we feel it is better to
  73.    discuss examples we know than to attempt to be abstract.
  74.  
  75.    In the ARPANET mail service, composition and reading is done with
  76.    user programs such as HERMES, MSG, MM, etc., while mail transmission
  77.    is done by system programs such as MAILER (sending) and FTPSRV
  78.    (receiving).
  79.  
  80.    One element of the ARPANET mail service is the assumption that every
  81.    source of mail can have a direct interprocess communication
  82.    connection (via the NCPs) to every destination for mail.  (There are
  83.    some cases where special handling and forwarding of mail violates
  84.    this assumption.)
  85.  
  86.    Mailbox names are of the form "MAILBOX@HOST", and it is assumed that
  87.    MAILBOX is a destination mailbox on that host.
  88.  
  89.    The messages are actually transmitted according to the provisions of
  90.    the File Transfer Protocol.  Mail may be transimitted via either the
  91.    control connection (MAIL command), or via a data connection (MLFL
  92.    command).  In either case, the argument specifies only the mailbox
  93.    since the destination host is assumed to be the host receiving the
  94.    transmission.
  95.  
  96.       For example:  messages sent from Postel at USC-ISIF to Cerf at
  97.       USC-ISIA would arrive at ISIA with the argument "Cerf" but no
  98.       indication of the host.
  99.  
  100. COMPOUND AND ALTERNATE NAMES
  101.  
  102.    Mailboxes are of the form "mailbox@host" where mailbox is usually a
  103.    name like "Postel" and host is a host identifier like "USC-ISIF".  In
  104.    some cases it will be useful to allow the host to be a compound name
  105.    such as:
  106.  
  107.       USC-ISIA
  108.       ARPANET-ISIA
  109.       SATNET-NDRE
  110.       PPSN-RSRE
  111.       HOST1.SRINET
  112.       LSCNET/MAILROOM
  113.  
  114.  
  115.  
  116.  
  117.                                    2
  118.  
  119.  
  120.                                                                         
  121. RFC 771                                                   September 1980
  122.                                                     Mail Transition Plan
  123.  
  124.  
  125.  
  126.    or even the name of an organization:
  127.  
  128.       BBN
  129.       ARPA
  130.       MIT
  131.       SRI
  132.  
  133.    The only restriction is that "@" not appear in either the "mailbox"
  134.    or the "host" strings in the destination address.
  135.  
  136.    To actually send the message the mailer program must convert the host
  137.    string into the physical address to which to transmit the message.
  138.    This name-to-address conversion is typically done by looking the name
  139.    up in a table and finding the physical address in another field of
  140.    that table entry.  This means that all the compound and organization
  141.    names (and any other alternate names or synonyms) must also be in the
  142.    host table.
  143.  
  144. HIDDEN HOSTS
  145.  
  146.    Sometimes the mailbox part of the destination address is a compound
  147.    name and is used to mark a set of mailboxes which are not really on
  148.    the host at all, but rather on another host which is connected to
  149.    this host in a non-standard way.
  150.  
  151.    It is important to users of computer mail that replies to messages
  152.    may be easily composed with automatic assistance from the mail
  153.    processing programs.  To preserve this capability it is important
  154.    that a host understand the mailbox part of every address in every
  155.    message it sends if the host part of the address is itself.
  156.  
  157.    That is, for every message, in every header field, in every address
  158.    "m@h", host h must understand all values of m.  Thus when a host
  159.    prepares a message it should check all the addresses that appear in
  160.    the header and for any address whose host part is this host the
  161.    mailbox part should be verified.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.                                    3
  177.  
  178.  
  179.                                                                         
  180. September 1980                                                   RFC 771
  181. Mail Transition Plan                                                    
  182.  
  183.  
  184.  
  185. THE TRANSITION PLAN
  186.  
  187.    The basic ground rules for the transition are:
  188.  
  189.       1.  ARPANET mailbox names must continue to work correctly.
  190.  
  191.       2.  No changes should be required to mail editor software which
  192.       parses message headers to compose replies and the like.
  193.       Specifically,  non-ARPANET mailbox designators must be
  194.       accommodated without change to the parsing and checking mechanisms
  195.       of mail processing programs.
  196.  
  197.       3.  Automatic forwarding of messages between NCP and TCP
  198.       environments without user (or operator) intervention.
  199.  
  200.    For the communication of messages between NCP and TCP hosts a mail
  201.    relay service will be provided on a few hosts that implement both TCP
  202.    and NCP.  These will be "well known" in the same sense that sockets
  203.    or ports for contacting Telnet or FTP servers are well known.
  204.  
  205.    To make use of these relay servers changes will be made to the mailer
  206.    programs.  The mailer program will be responsible for determining if
  207.    the destination address of the message is directly reachable via the
  208.    interprocess communication system it has available (TCP or NCP or
  209.    both), or if the mail must be relayed.  If the mail must be relayed,
  210.    the mailer must choose a relay server and transmit the message to it.
  211.  
  212.    The basis for the decision the mailer must make is an expanded host
  213.    name table.  There will be a table which translates host names to
  214.    physical addresses.  The physical addresses in this table will be the
  215.    32-bit Internet addresses. (This makes sense for even NCP-only hosts,
  216.    since after 1 January 1981 even they must use 96-bit leader format
  217.    which requires 24-bit ARPANET physical addresses).  Each entry in
  218.    this table will also have some flag bits.
  219.  
  220.    The flag bits will include information to indicate if the host in
  221.    this entry is (1) a  NCP host with "old tables", (2) a NCP host with
  222.    "new tables", (3) a TCP host, or (4) some other kind of host.  All
  223.    TCP hosts are assumed to have "new tables".  "Old tables" are those
  224.    without these flag bits, while "new tables" do have these flags.
  225.  
  226.    A separate table may be useful to list the addresses of the hosts
  227.    with relay servers.
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.                                    4
  236.  
  237.  
  238.                                                                         
  239. RFC 771                                                   September 1980
  240.                                                     Mail Transition Plan
  241.  
  242.  
  243.  
  244.    When a message is sent to a relay server, the control information (in
  245.    the argument of the mail transfer command) must be augmented to
  246.    include the destination host identifier.
  247.  
  248.    The relay server may accept messages to be relayed without knowing
  249.    that destination mailbox is actually reachable.  This means that it
  250.    may later discover that the destination mailbox does not exist (or
  251.    some other condition prevents mail delivery).  To be able to report
  252.    the error to the originating user, the mailbox (mailbox@host) of the
  253.    originating user must be included in the argument of the mail
  254.    transfer command.  If the argument does not contain the address of
  255.    the originating user no error response is attempted.  The error
  256.    report, which is itself a message, does not carry an originator
  257.    address in the command argument to avoid the possibility of a endless
  258.    chain of error reports (however, an originator address does appear
  259.    the header).
  260.  
  261.    Since the originating host will act as if the mail was successfully
  262.    delivered when it is accepted by the relay server, it deletes any
  263.    back up copies of the message it was keeping in case of errors.  For
  264.    this reason, the relay server must include the complete message in
  265.    any error report it sends to the originator.  The relay server should
  266.    parse the addresses in the argument before accepting a message.  If
  267.    it does not understand how deliver locally, or both relay and reply
  268.    (if the originating address is present) to the message, it should not
  269.    accept it.
  270.  
  271.    There are enough differences in the transmission procedure that the
  272.    relay server will use a distinct mail transfer protocol, separate
  273.    from the file transfer protocol.
  274.  
  275. MAIL TRANSFER PROTOCOL
  276.  
  277.    The mail trasfer protocol to be used by the relay server and all TCP
  278.    hosts is documented in reference [9].
  279.  
  280. CONNECTIVITY
  281.  
  282.    There are nine cases of mail exchange, the three by three matrix of
  283.    (1) old-table NCP hosts, (2) new-table NCP hosts, (3) TCP hosts.
  284.    There are also two transfer mechanisms:  file transfer and mail
  285.    transfer.  The diagonal is easy, each type of host can exchange mail
  286.    with other hosts of its type.  The other cases are more subtle.
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.                                    5
  295.  
  296.  
  297.                                                                         
  298. September 1980                                                   RFC 771
  299. Mail Transition Plan                                                    
  300.  
  301.  
  302.  
  303.    An old-table NCP host is assumed to have a table with 32-bit physical
  304.    addresses, but no flag bits.  It has NCP and file transfer.  It does
  305.    not have the separate mail transfer protocol.
  306.  
  307.    An new-table NCP host is assumed to have a table with 32-bit physical
  308.    addresses, and the flag bits.  It has NCP and file transfer.  It also
  309.    has the new separate mail transfer.
  310.  
  311.    An TCP host is assumed to have a table with 32-bit physical
  312.    addresses, and the flag bits.  It has the new separate mail transfer.
  313.    It probably has a file transfer, but does not use it for mail.
  314.  
  315.    1. Old-table NCP to Old-table NCP
  316.  
  317.       This transfer is direct and uses the old mechanisms -- NCP and
  318.       file transfer.
  319.  
  320.    2. New-table NCP to Old-table NCP
  321.  
  322.       This transfer is direct and uses the old mechanisms -- NCP and
  323.       file transfer.
  324.  
  325.    3. TCP to Old-table NCP
  326.  
  327.       This transfer must use a relay server.  The first transfer (from
  328.       the TCP host to the relay server) is via TCP and the mail transfer
  329.       protocol.  The second transfer (from the relay server to the
  330.       old-table NCP) is via NCP and file transfer protocol.
  331.  
  332.    4. Old-table NCP to New-table NCP
  333.  
  334.       This transfer is direct and uses the old mechanisms -- NCP and
  335.       file transfer.
  336.  
  337.    5. New-table NCP to New-table NCP
  338.  
  339.       This transfer is done with the NCP and the mail transfer protocol,
  340.       that is, using the old interprocess communication system and the
  341.       new mail transmission scheme.
  342.  
  343.    6. TCP to New-table NCP
  344.  
  345.       This transfer must use a relay server.  The first transfer (from
  346.       the TCP host to the relay server) is via TCP and the mail transfer
  347.       protocol.  The second transfer (from the relay server to the
  348.       new-table NCP) is via NCP and mail transfer protocol.
  349.  
  350.  
  351.  
  352.  
  353.                                    6
  354.  
  355.  
  356.                                                                         
  357. RFC 771                                                   September 1980
  358.                                                     Mail Transition Plan
  359.  
  360.  
  361.  
  362.    7. Old-table NCP to TCP
  363.  
  364.       This transfer must use a special relay server.  The first transfer
  365.       (from the old-table NCP to the relay server) is via NCP and the
  366.       file transfer protocol.  The second transfer (from the relay
  367.       server to the TCP host) is via TCP and mail transfer protocol.
  368.       This relay server must be special because the messages coming from
  369.       the old-table NCP host will not have the destination host
  370.       information in the command argument.  This relay server must have
  371.       a list of registered TCP user mailboxes and their associated TCP
  372.       host identifiers.  Since such a registry could be potentially
  373.       large and frequently changing (and will grow as more TCP hosts
  374.       come into existence) it will be necessary to limit the mailboxes
  375.       on the registry.
  376.  
  377.    8. New-table NCP to TCP
  378.  
  379.       This transfer must use a relay server.  The first transfer (from
  380.       the new-table NCP to the relay server) is via NCP and the mail
  381.       transfer protocol.  The second transfer (from the relay server to
  382.       the TCP host) is via TCP and mail transfer protocol.
  383.  
  384.    9. TCP to TCP
  385.  
  386.       This transfer is direct and uses the new mechanisms -- TCP and the
  387.       mail transfer protocol.
  388.  
  389.    In general, whenever possible the new procedures are to be used.
  390.  
  391. MULTIPLE RECIPIENTS
  392.  
  393.    A substantial portion of the mail sent is addressed to multiple
  394.    recipients.  It would substantially cut the transmission and
  395.    processing costs if such multiple recipient mail were transfered
  396.    using the multiple recipient technique available for use in both the
  397.    old file transfer protocol [12] and new mail transfer protocol [9].
  398.  
  399.    The relay servers will attempt to use a multiple recipient commands
  400.    whenever applicable on transmitting messages, and will accept such
  401.    commands when revceiving messages.
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.                                    7
  413.  
  414.  
  415.                                                                         
  416. September 1980                                                   RFC 771
  417. Mail Transition Plan                                                    
  418.  
  419.  
  420.  
  421. COMPOSITION AND READING PROGRAMS
  422.  
  423.    The impact on the mail composition and reading programs is minimal.
  424.    If these programs use a table to recognize, complete, or verify host
  425.    identifiers, then they must be modified to use the new table.
  426.  
  427.    To assist the user in replying to messages it will be important that
  428.    all addresses in the header fields (TO:, CC:, etc.) be complete with
  429.    both the mailbox and host parts.  In some cases this has not
  430.    previously been necessary since the addresses without host parts
  431.    could be assumed to be local to the originating host, and the sending
  432.    host was recorded by the receiving host.  When the messages were sent
  433.    directly the originating host was the sending host, but when messages
  434.    are relayed the originating host will not be the host sending the
  435.    mail to the destination host.
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.                                    8
  472.  
  473.  
  474.                                                                         
  475. RFC 771                                                   September 1980
  476.                                                     Mail Transition Plan
  477.  
  478.  
  479.  
  480. REFERENCES
  481.  
  482.    [1]     Cerf, V., "The Catenet Model for Internetworking," IEN 48,
  483.            DARPA/IPTO, July 1978.
  484.  
  485.    [2]     Postel, J., "Internet Protocol," RFC 760, USC/Information
  486.            Sciences Institute, NTIS ADA079730, January 1980.
  487.  
  488.    [3]     Postel, J., "Transmission Control Protocol," RFC 761,
  489.            USC/Information Sciences Institute, NTIS ADA082609,
  490.            January 1980.
  491.  
  492.    [4]     Postel, J., "Telnet Protocol Specification," RFC 764,
  493.            USC/Information Sciences Institute, June 1980.
  494.  
  495.    [4]     Postel, J., "File Transfer Protocol," RFC 765,
  496.            USC/Information Sciences Institute, June 1980.
  497.  
  498.    [5]     Postel, J., "Assigned Numbers," USC/Information Sciences
  499.            Institute, RFC 762, January 1980.
  500.  
  501.    [6]     Postel, J., "Internet Protocol Handbook," USC/Information
  502.            Sciences Institute, RFC 766, July 1980.
  503.  
  504.    [7]     Feinler, E. and, J. Postel, "ARPANET Protocol Handbook,"
  505.            NIC 7104, Network Information Center, SRI International,
  506.            January 1978.
  507.  
  508.    [8]     Crocker, D., J. Vittal, K. Pogran, and, D. Henderson,
  509.            "Standards for the Format of ARPA Network Text Messages,"
  510.            RFC 733 7104, Network Information Center, SRI International,
  511.            November 1977.
  512.  
  513.    [9]     Sluizer, S. and, J. Postel, "Mail Transfer Protocol,"
  514.            USC/Information Sciences Institute, RFC rrr, September 1980.
  515.  
  516.    [10]    Postel, J., "Internet Message Protocol," USC/Information
  517.            Sciences Institute, RFC 759, August 1980.
  518.  
  519.    [11]    Postel, J., "A Structured Format for Transmission of
  520.            Multi-Media Documents," USC/Information Sciences Institute,
  521.            RFC 767, August 1980.
  522.  
  523.    [12]    Harrenstien, K., "FTP Extension: XRSQ/XRCP,"
  524.            SRI International, RFC 743, December 1977.
  525.  
  526.  
  527.  
  528.  
  529.  
  530.                                    9
  531.  
  532.